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(54) Apparatus and method for authenticating transmitted applications In an Interactive 

Information system 

(57) An executable interactive program is combinoJ 
with auCDoArtdeo data for transirtssion. The program is 
divided (40. 41) into modules. simHarto computer files, 
and a Directory Module is created wtiich links program 
modules. Security tor the executable application is pro- 
vided (52.53.54) by attaching a signed certificate to 
respective Directory Modules. The integrity of respec- 
tive modules is monitored by hashing (46) respective 
modules and including (50) respective hash values in 
the Directory Module. A hash value of the Directory 
Module containing the other hash values is generated 
(46). encrypted (51) and attached (53,54) to the Direc- 
tory Module. At a receiver the certificate is decoded and 
checked for authenticity of provider. If the certificate Is 
authentic the program may be executed but only H 
receiver generated hash values of respective program 
modules are identical to con-esponding hash values 
contained in the Directory Module. 
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Description 

This invention relates to a methcxl and apparatus for insuring that data accepted by an interactive television system 
is authorized data. i r 

5 Interactive television (TV) systems are known from for exanple United States Patent No. 5,233,654. Interactive tel- 

evision systems typically involve the transmission of programming and/or control data (hereafter PC<iata), as well as 
audio and video information, to respective receiving apparatus. The receiving apparatus decodes the PC-data, and 
appDes it to some type of control apparatus for automatic use by the receiver or selective use by the user of the receiver. 
The control apparatus may take the form of a computer, for example, and the use may include downloading selective 

10 e.g., financial data for sutssequent user manipulation. 

As envisioned herein, information in the interactive television system (ITVS) is transmitted in compressed digital 
form. The receiving end of the system includes an integrated receiver decoder (IRD) for receiving and decompressing 
the transmitted information and providing decoded audio, video and PC-data to respective processors. The audio arxJ ' 
video processors may be audio and video reproduction devices or a television receiver and the PC^ata processor may 

75 be a computer. Ideally the system will only provide well tested PC-data provided by authorized service providers, arxl 
under such conditions there is little likelihood of transnnitted information actually damaging respective receivers. How- 
ever, if a large nunrtfjer of service providers are authorized to use the system, it becomes vulneratDle to a) invasion by 
unauthorized users and intentional inffiction of damage to system users, and b) careless preparation of PC-data and 
consequent unintentional damage to system users. The ability to broadcast PC-data to tens of thousands of IRD's 

20 simultaneously, multiplies the potential disruption that may be inflicted by ill behaved software many fo\d. Thus there is 
a need for measures to assure protection of respective ITVS receivers from both ill behaved and unauthorized PC-data. 

A receiver errdDodiment of tine invention includes an IRD which is responsive to a transnriitted program guide for 
selecting signal packets of PC-data. The IRD tennporarily stores the selected PC-data. Autiiorized PC-data will include 
a certificate. A PC-data processor is configured to separate tiie certificate arKJ to check it for autiienticity. The processor 

25 hashes portions of the PC-data and compares the generated hash values with hash values transmitted with the PC- 
data and corresponding to tiie same portions of PC-data. H the hash values are identical and the certificate is autiientic. 
the system is conditioned to execute the transmitted program. 

A transmitter embodimerrt includes software generating apparatus for providing an interactive program. The pro- 
gram is divided into modules arxl a Directory Module is generated. Respective modules are hashed and the generated 

30 module hash values are included in the Directory Module. The modules are then conditioned for transmisdba 
The invention will be described with the aid of the following drawings. 

BRIEF DESCRIPTION OF THE DRAWINGS 

35 FIGURE 1 is a t^ock diagram of an interactive TV signal encoding system embodying an aspect of the present 
invention: 

FIGURE 2 is a pictorial diagram of a portion of an exenplary AVI signal 
FIGURE 3 is a pictorial diagram of an exemplary transport packet 

FIGURE 4 is a pictorial diagram of the format of an exemplary AVI application, useful in describing the invention. 
40 FIGURE 5 is a tatjie of the contents of an exemplary transmission unit header. 

FIGURE 6 is a tat)le of the contents of an exemplary Directory Module of a AVI application embodying the invention. 
FIGURE 7 is a flow diagram illustrative of the process of applying security4»rotertion to an AVI application emtxxj- 
ying the invention. * 

FIGURE 8 is a block diagram of exemplary receiver apparatus emfc>odying the irrvention. 
45 FIGURE 9 is an expanded block cfiagram of an exenplary processor which may be inplemented for the processor 
of tiie FIGURE 8 apparatus. 

. FIGURE 10 is a flow chart showing operation of a portion of the receiver apparatus of FIGURE 8. and which 
describes a receiver embodimerrt of the ihverrtion. 

FIGURE 11 is a flow chart of an exemplary process for autherrticating a certificate and is an embodiment of tiie 
so invention 

FIGURE 12 is a pictorial representation of a preferred Directory Module format according to the invention. 

The invention will be described in the environment of a compressed digital transmission system, as for exarrple a 
direct broadcast satellite system. It is presumed that a single satellite transponder will accommodate a plurality of 
55 respective TV programs in time division multiplexed format . 

Referring to FIGURE 1, a packet multiplexer 16 provides, at its output port an audio-video-interactive (AVO pro- 
gram. Similar such devices 26 generate alternative AVI programs. A program guide, which includes information associ- 
ating the audio, video and interactive components of respective AVI programs via service channel kjentif iers (SCID's). 
is provided in a transmission format similar to the AVI programs by a processing element 27. The prograrn guide and 
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respective AVI progr^ are applied in transport packet form to respective input ports of a channel mul1J>lexer 28. The 
ctennel multiplexer 28 may be of known construction for equally time division multiplexing respechve packet signate into 
a single sigrS stream or it may be a statistically controlled multiplexer. The output of the mulbplexer 28.S caL|pled to a 
forward error coding (FEC) and signal interleaving apparatus 31 . which may include Reed-Solomon and Trellis encod- 

s ers. The output of the FEC 31 is coupled to a modem wherein the multiplexed signal is condibonol for app'Kalion ta 
for example a satellite transponder. An exemplary statistically multiplexed packet signal is illustrated m FIGURE 2. and 
an exemplary format for respective packets is iflustrated in FI(ajRE 3. 

AVI formation is controlled by a system program controller 5. Program controller 5 may have a user interface by 
which particular programs and respective program signal components are selected. The programcontroller assigns 

10 respective SCID's tor respective audio, video and interactive components of respective programs. The presumption is 
that respective receivers will access a program guide to detemiine which SCID's associate AVI P[09ram compc^ 
nents. and then select transport packets from the transmitted signal stream containing the assoaated SCIDs^The 
audio, video and interactive components are assigned different SCID's so that one or niore of the ~^'?e"^'l°"f 
AVI program may conveniently be utilized in the formation of alternate AVI programs. Using diffenng SCID s also facili- 

13 tates editing aucfib from one program with video from another ete. ^ 

A given AVI program may Sclude a variety of signal component sources. Shown in FIGURE 1 are an intejacjve 
component source 1 0. a vkleo source 17. and frst and second audio sources 20 and 23 (bjingual audio), "-"^o"'^ 
5 <Snv™nicates with respective sources for time managemertand/w 

is coupled to a video signal compression apparatus 1 8. wWch may compress signal according to the video ""Presaon 
standi promoted by the Moving Pictures Experts Group (MPEG). Similarly the respect«.e audio »9nals from fte 
sources ^ and 23 are applied to respective compression apparatus 21 a,^ 24. These "'^h^TlZ^^S 
compress the respective audio signals according to the audio compression starxlard Prar^ted by Moving Pffihjr« 
E^rts Group ^G). Associated audio and video signals compressed according to the MPEG protocol are synchro- 
^ with ttie use of presentatfon time stanps (PTS). which are provided by « ^^^'"^^^^^ 
the audio and video may be temporally related, the reader's attention is directed ^ "JTERN AT^QNALORG AN^^ 
FOR STANDARDIZATION. ISO/IEC JTCi;SC29/WG11: N0531. CODING OF MOVING PICTURES AND ASSOCI- 
ATED AUDIO. MPEG93. SEPTEMBER. 1993. ,o «^ ok 
The compressed audio and video signals are applied to transport Packet formere '^^'^^^I'.S^n^' 
Audio and >Seotransportpacket processors are known and wfll not be described. Suffice « tof^Vj^^ '^t,'?^^ 
^s divide the conpre^ed data into payloads of predetermined numbers of bytes and attach -dentifyjng 
including SCID's. as indtaated in FIGURE 3. For detailed information on a video signal t^i^port packet processor, m^^^ 
rSSer te directed to United States Patent No. 5.168.356. The packet processors are coupled to the P^J^^^ 
which time division multiplexes the signal components. The transport packet proc^ may include a birffermemonr 
for temporarily storing packetized data to accommodate the multiplexer senrfdng other components. The packet proc- 
essors include PACKET READY signal lines coupled to the multiplexer to indicate when a padiet is a^'^«- 

Interactive programs are created, via known techniques, by a programmer operabng interacbve^wmpo^^^^^ 
source or progrkrn?»ng element 10. which may be a computer or personal computer (PC)^ In *^"9jf 
the programing element 1 0 interfaces with a memory 1 1 and memory controller 12. and the completed 
sSrWTn the m^ory 1 T. After completion, the application may be condensed or translated to some native code to con- 

'^r*'^!;?S^fS the application, portions of the programs are fonnatted imo modules, transrrt^^^^ untej^l 
packets as shown in FIGURE 4. The packets are similar in tonn to the transport Pa*«s^desaibed ato>^ A tra^^ 
Sn unit consists of plurality of transport packets. Each transmission unit indud^ a headen«d«^ a^ 
information descriptive of the transmission unit contents, and a plurality of basic packete each of wNch '.-^"^^ pw 

45 tion of the codewords of the application. A module is divided into transmission units to ^«^t« "[^f 

tion from different modules. Preferably, interieaving of fransmission units is Perrrttted^ ^^Tr!2^J^^ 
packets from different transmission units is not. For a more detailed description of the tomiation of an applicaton and 
transmission units etc. the reader is referred to United States Patent No. 5.448.568. , ^- ,^ 

^!SesL similar to computer fOes. and are of different types. Afirst type of module is a ^jfectory Module wh^h 

50 contains information to intenelate respective fransmission units and modules as 

is a Code Module which comprises executable code necessary to program a compubng device at a receiver to perform 
or execute the application. A thiitl module type is a Data Module. Data Modules include non-«ceaitable date used^ 
L execution oHhe application. Data Modules tend to be more dynamic than Code Modul^. that tOf^^"^"^^"^ 
change during a program while Code Modules generally do not A fourth type of module is ^'^onated a S^nal Mod^^^ 

55 This module is a special packet including information to frigger receiver intermpts. which may be ubFized for synchron 
zation of e.g.. video with application program features, or to suspend operation of a"^P''°^*°":°: ° J^^^^ 
ation of a program etc. Synchronization is effected via inclusion of presentation tme stamps. Date. Directory. Code and 

Signal Modules are exanples of the PC-date. .lo ma« 

The respective modules may be error coded by the programming element 10. For example the entire module may 
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undergo cyclic redundancy coding CRC. and en^or check bits may be added to the end of the module. 

Each transmission unit, TU, is configured with a header including information about the TU. Table I, shown in FK3- 
URE 5. illustrates exemplary types of Information included in each TU header packet . The header includes a versbn 
number. The version number is included to indicate when a diange is made to the application during the presentation 
of the AVI program. A receiver decoder may be arranged to update an executing application responsive to detecting a 
change in version number. The Module ID is similar to a computer ffle identifier and is provided by the application pro- 
grammer. The Module Transmission Unit Byte Offset is a number which indicates the byte location in the nxKlule of the 
first code/data byte of the payload of the TU. The Lengtii (bytes) Of Transmssion Unit indicates the size of the TU 
and/or tiie location of the last code/data byte in the TU. 

Table II of FIGURE 6 illustrates representative types of data included in the Directory Module. The Directory Module 
includes a header with an Application identifier, AID, a field indicating the application type, a field which includes type 
qualifiers, a field which indicates the amount of memory required to store and execute the application, a field indicating 
the number of modules contained in the application, and a field or fields (FIRST SECURITY INFORMATION) which may 
include security data such as authenticating data. It will be appreciated that the respective fields listed above, or those 
that follow, need not occur in the order illustrated. A data portion of the Directory Module includes data for each module 
similar to the header data for tine respective nrKxlules. In addition there is a string table which is a list of respective appli- 
cation module names in ASCII format. The data section for each module may also include a field or fields (FURTHER 
SECURITY INFORMATION) for security data related to the respective module. Alternatively, tfiis data may be included 
with the more general directory information in the first security Information field. The contents of the nrKxiule security 
information fields will be discussed in detail below. 

For transport packet formation, the interactive component source 1 0 may be programmed to generate the actual 
transmission units and ti*ansport packets, however in the embodin^nt of FIGURE 1 , a separate code/data packet proc- 
essor 14 is included. The code/data packet processor accesses tiie respective areas of the memory 1 1 through tiie 
memory controller 12 and generates packets in a sequence representing a respective application (FIGURE 4). 

The packet multiplexer 16 is ananged to provide packets according to a particular schedule. The schedule is nom- 
inally determined by the bandwidth requirements of the AVI components. If there is multiplexing contention between tiie 
respective AVI conponents it is preferred that the signal component with packets that occur least frequentiy be 
assigned the higher multiplexing priority. 

The specifics of the packet multiplexer 16 will not be described because multiplexing Is a mature art and those 
skilled in digital signal processing will readily be able to design a multiplexer to satisfy their particular requirements.. 
Suffice it to say that the packet multiplexer 1 6 may be arranged using tiiree stale logic switches with input ports coupled 
to the respective conponent signals and their output ports coupled to the multiplexer output port A state machine may 
be arranged to control tiie logic switches responsive to priorities established by the controller 5 and the respective 
packet ready signals provided by the packet formers. 

Security in the AVI system is based on the close integration between techniques implemented by tiie AVI system 
controller and security codes resident in all AVI system conpliant receivers. The security is based on public key cryp- 
tography using the Rivest, Shamir, and Adieman, RSA. algorithm or the Data Encryption Standard. DES. The algorithm 
preferred by the present inventors is the RSA algorithm, using nxxjulus and exponent sizes which are respectively mul- 
tiples of four (eight-bit) bytes. The general type of security protection resides in autiientication of a certificate supplied 
wiiHi Directory Modules, and hash values generated over respective other application modules. 

A special class of RSA protocols is that in which the public exponent is 3. An advantage resides in the fact that sig- 
nature checking speed may be enhanced by inclusion of "helping" information of the type described below. 

Conskier that a reefer is to verify that S is a RSA signature over data D. where the public modulus arKi exponent 
are N and 3 respectively. To verify, the receiver essentially has to show that S ^ = D(nriod N) . Nominally this requires a 
division/nrxxiulo operation by N. which is computationally difficult and time consuming. Since multiplication is a compu- 
tationaOy simpler and faster operation, a checking operation which relies on multiplication rather than division v«ll sig- 
nificantly speed up the operation. 

Consider the quotients Q1 and 02 defined as follows 

S /N=Q1+R1 ; S-R1/N=Q2+R2 ; R2=D ; H S^=D(mod N) . That is. the values Q1 and Q2 are whole number 
quotients derived from the signature by division by N. R1 and R2 are respective remainders after division. Given any N. 
S and D of size at most T bits, where S < N and D < N, then there exist quotients 01 , 02 of size at most T bits which 
will verify S = D(mod N) using the algorithm outlined immediately below. If the values 01 and 02 are calculated by 
the application pvogrammer (e.g. in non-real time) ar»d transmitted within the Directory Module with the signature S, it 
can be shown that a fast check on the signature may be performed as follows. 
At tiie receiver, extract S. 01 , 02 from the Directory Module and; 

1. compute A = 8^ 

2. compute B = 01 times N 

3. compare A > B; If A< B quit, signature cannot check. 
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else "rf A> B 

4. compute C = A- B 

5. coiTpare C < N; If C > N quit, signature cannot check, 
else if C < N 

6. conpute E = CtimesS 

7. compute F = Q2timesN 

8. Compare E > R If E < F quit, signature cannot check. 

else if E > F 

9. compute G = E - F 

75 10. Compare G = D , if not signature does not check. 

Note that all arithmetic operations are simple multiplications or subtracfions. The detection of ^ ^^"'"^^ .^9^^^ 
may occur at steps 3. 5. 8 or 1 0. If an erroneous signature is detected at steps 3 or 5. very IrtUe computatonal time has 

"^^tS^^J? rt;eivers are provided with the public keys (and desirably helping quotients Q1 and CC) of tiie respec^e 
system providers for decrypting signed certificates included with POdata to determine P^^^^^f^-^'J^ 
aJrthentidty is notconfimS the received application is immediately dumped from the recover. Central ^su* a secu- 
rity system isthe assignment of unique identifiers. ID'S, to application providers and ^^.^^V^^^'" 
system controller allocates unique e.fl. 32-bit ID'S to each trusted AVI appBcafon provjder and "^^^,^^^"=1*^ 
fi the aoDlication provider's public key. The certificate is essentially the system controller's digital signature on the 
^TiSSe?sT^Tc k^y and includes fields such as the expiration date of the certificate, the ID of thf Proj«der^ 
BmH on the amiint of storage an application with this ID can use in the fne system of ^V^^r^tllSSt^ 
controDer may employ a plurality of different private-pubOc key pairs, and tiie certificate may include flags to designate 
which of ttie plurality of public keys the receiver should use to decrypt respective certificates. 
30 A certificate for application providers will nominally include: ^ . ^ w i, n,-N. 

CERTIFICATE.FLAQS (which identify ttie certif icate type and may include ttie system controBer-s public key flag). 
PROVIDERJD. (which indicate length of provider ID); 
PROVIDER_EXPIRE. (which indicates application lifetime): 

PR0VIDER_ALrn-10RIZATI0N_FLAGS, 
35 PROVIDER_STORAGE_L»^IT, (which indicates aBotted receiver memory); 
PROVIDER_NAME. (tiie application provider's name) 

PROVIDER FIXED CERT. (wWch is the providers public key). ^ ^ 

This foregoing certificate infonrotion is hashed modulo 1 28. and the hash value is append«l thereto. 
The CERTIFICATE FLAGS mentioned above include authorization flags which grant/deny tiie receiver P/ocessore 
access to privileged actons. Exarrples of representative privileges accessed via flags are listed immediately below and 
include: 

I . ttie ability to tfe downloaded from a broadcast link; 

2 ttie ability to be downtoaded from a local link (e.g. connected via a local IRD port); 

3. ttie ability to be downtoaded from a local remote link (e.g. via a telephone link); K-h..««n wideo 

4. The ability for an application to switch tracks in the context of ttie same program (e.g. to wntch between video 

tracks 1 and 2); i. : 

5. ttie ability to establish a broadcast connection {e.g. to change TV programs or channels). 

6. the atxl'ity to estatilish a local connection; 
so 7. ttie ability to establish a remote connection; 

8. the atsility to control external devices: 

9. ttie ability to download unchecked modules; 

10. ttie ability for an application to use cryptographic features; and 

I I . ttie ability for an application to request ttie user for permission to access files which have user restnctons. and 
55 12. ttie ability to activate a resident OCODE monitor for remote debugging. 

These flags are part of botti ttie provider certificate and ttie application auttiorization field directory An applic^tonmi^ 
have ttie auttiorization flags set at botti locations before it is permitted to perfomi '^"1?^/™ to SSr 
receivers contain a BOX auttiorization mask, in nonvolatile storage, which is programmed to permit access to particular 
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privileges, or to prevent certain privileged actions. 

Each application provider selects his own cryptographic putjlic-private key pair, and has his put)lic key certified by 
the AVI system controller (for exanple by notarized request). The application provider is constrained by certain guide- 
lines in selecting the public key. The constraints relate to the capabilities of the receiver hardware. In particular, near 

5 term consumer electronic receivers will include minimal memory and relatively unsophisticated processors, factors 
which affect authentication processing speeds and times, and thus the size and form of put)lic keys. Examples of con- 
straints may be that public keys are to be 51 2 bits or less and that the number of bits be a power of two etc. 

A special group AVI system ID may be reserved for programs designed to perform receiver or system maintenance. 
This system ID will be attached with a service provider ID. If a program contains both the special group ID and an 

10 authentic provider ID. the corresponding maintenance program may obtain access to more secure portions of the 
receiver, depending upon the ID of the particular provider. For exanple the application provider rray be the system con- 
troller arxi the attached application may be for updating entitiements in a smart card, or performing a system perform- 
ance check. Alternatively, the application provider may be associated with inpulse buying commercials and tiie 
program may be related to checking a users debits against his credit, or to facilitate revenue collection, etc. On the other 

15 hand, if a group ID is not the special group AVI system ID, the functions availat)le to the application may be Gmited to 
functions availat^le to all applications. 

Manufacturers of particular receiver apparatijs may be assigned special manufacturer ID'S. Any application having 
the manufacturer ID may be authenticated by a special authentication process, resident in the receiver, and imple- 
mented by the manufacturer during assemk^ly of the receiver. Programs containing the manufacturer ID will access only 

20 receivers produced by the particular mcinufacturer, and rray function to access a particular set of functions built irtto the 
receiver by the nr^nufacturer. This type of application may be utilized to up>grade receiver operating software. 

There may also be network operators who have software/hardware resident in particular receivers. These network 
operators may also be assigned special ID'S to allow selective access to the software/hardware of all network receivers. 
The network operators may include their own autinentication process resident in the software/hardware of the network 

25 receiver. 

Whether an application is a special system type, or a manufacturer type or a network type is indicated in the Direc- 
tory f^odule (Table II) in the Application Type field. The Application Qualifier fiekl may include information identifying the 
manufacturer, or network operator, etc. 

Security is applied to an application as follows. After an application provider has generated an application and 

30 formed respective modules including the Directory module, he determines which parts of the application are to be pro- 
tected. In all instances the Directory Module will be protected. In addition each module corrtaining an entry point will be 
protected. Modules without entry points are protected at the providers discretion, and Data Modules are protected at 
the providers discretion. It should be recognized that portions of the data in data modules may frequentiy change, and 
thereby put a relatively heavy security processing Ixjrden on the encoder and receiver, if Data Modules are protected. 

35 Therefor Data Modules may frequentiy be transmitted unprotected. Having selected ttie modules to be protected, the 
provider forms a list of tiie modules selected for security protection, and the mode of protection for respective modules, 
and enters this list in the Directory Module in the fiekJs designated security information. In a partfeular AVI system this 
nxxlule list may be included in general directory information i.e.. the first security information portion of the Directory 
Module. In an altemative AVI system, information irxjicating whether a particular module is protected may be included 

40 only in the further security infornr^ation fields of the respective module in the directory. Part of the receiver system pro- 
gramming will include a routine to examine the Directory for nrxxlule security information, arxl perform security process- 
ing on respective modules according to this information. 

Module protection itiay take several forms. The first is sinply to encrypt the selected module with the application 
providers private key. A second method is to perform a "hash* function over the module arxJ include tiie "hash" value in 

45 the Directory Module in the further security information field for the respective module. A third method is to perform a 
hash function over the module, include the hash value in the Directory Module and encrypt the selected module with 
the application providers private key. A fourth method performs a hash function over the selected module, attaches Ihe 
hash value to the module, encrypts the module plus hash value, and places a replica of the encrypted hash value in the 
Directory Module. In each of the foregoing examples, security processing of the Directory Module is done after all other 

so nnodules are processed and the security information for respective modules has been entered in the Directory Module. 
The preferred method corrprises performing hash functions over respective modules, inserting the respective hash 
values in the further security information fields of the directory module and subsequently performing a hash function 
over the Directory Module. The hash value of the Directory Module is then encrypted witti the providers private key,. 
A ta-usted application provider will be assigned a signed certificate which includes items such as tiie providers pub- 

55 lie key the providers ID. an expiration date of the certif icale, possibly the amount of storage allocated the provider at the 
receiver etc. This certificate is signed witii the system controller's private key The encrypted hash value is appended 
to the signed certificate and the combination is appended to the Directory Module. The directory Module arxi all other 
modules are provided to tiie system controller in plaintext Data Modules which are selected for protection and which 
are frequentiy changing, are protected by means of a signatijre of the provider on the hash value over tiie Data Module, 
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which signature is made part of the respective module. 

It is possible that the application provider is in fact an overseer of a subgrofl? of lesser application providers. In this 
instance the application provider may provide a sut)-certificate signed with the application providers private key and 
including a sub-providers public key, the su^providers ID. an expiration date of the certificate, possibly the amourrt of 
5 storage allocated the sub^rovider at the receiver etc. This subKsertificate will also be appended to the Directory Module 
along with the certificate assigned the application provider. _^ 

The preferred mode of protection is not secure in that it does not preclude prying eyes from detecting/interpreling 
the transmitted inforrration. However the protection. i.e.. incluston of the certificate and hashing of the data, « advan- 
tageously simple to perform and does provide assurance tiiat the data comes from an authorized source and that the 
10 integrity of the received data is insured, (Hautinenticated at the receiver). ^ ^ 

Untrusted application providers, i.e., providers who may be careless in application generation and threaten the 
integrity of an AVI senrice. are not provided certificates to be appended their respective applications. Applications pro- 
vWed by untrusted providers are subjected to certification by a trusted certifying authority. The certifying authority may 
inspect the integrity of the application and then process the applications of the untrusted appOcation providers for pro- 
15 tedion purposes, and ultimately pass the processed application to the system controller. ^.^ ^ 

Security processing will be further described with reference to FIGURES 1 and 5. FIGURE 1 incliKles distinrt hash- 
ing and encrypting elements 29. and 30. however it will readily be recognized, by ones skilled in the art of digital signal 
processing, that both functions may be performed in software executed by tiie uPC or digital signal processor. DSP. 
which may be included in the element 10. Once tt^e application has been generated and stored {40} in the memory 11 . 
2c the programmer will setect/determine {41) the modules which are to be security protected. These rnodules willbe 
tagged with an index (i). The Directory Module is assigned the highest index so that it wiB be processed last. Each nod- 
ule to be processed is assigned a "Change" flag which is set to a "1 ". The AVI system repeatedly transmits tine applica- 
tion during an AVI program. Nominally Code and some Data Modules remain unchanged during the program, but some 
e g Data Modules may change. During the repeated transmissions of ttie application it is prefen-^ncrt to reijrocess 
unchanged modules for security, but rather only to reprocess tine modules which actually change. The Change flags 
are established to alert the security processing function which modules require reprocessing due to <*>anges dunng the 
duration of a program. Initially the "Change" flag of each module to be security protected is set to tfie change mode. 
The element 10 also determines if a certificate from ttie system contioller is available. 

An operating index T is set to zero {42} and tiie first module. M(0). is accessed {43} from the memoi7 11. The 
-Change" flag for tiie module is tested {44} and reset {45}. If ttie module has been previously proceed andttie 
-Change-flag indicates no change, ttie system jumps to step {56}. increments ttie ''^f J^" ^^^^"'^^^f ® ""f^ "1°^" 
ule If ttie -Change" flag indicates ttiat a change has occurred in ttie module, it is applied {46} to a HASH function proc- 
essor 29 The particular hash function is maintained relatively simple to fimit processing requirements ""posed wi 
respective receivers. The function is preferably a one-way function. The hash function should be connputetional^ fast 
and extremely difficult to decipher or break. An exemplary hash function is based on a vector W of 256 ^^oj^ 
each 128 bits in lengtti. Data to be hash processed (hashed) is segmented into 256*it exclusive blocks of data D. 
where D = d , . dg. dg. d4. 6255- A basic hash function BH(D) is defined: 



25 



30 



35 



^ 128 

40 BH(D)=2^xWx'™xJ2 

x-1 



45 



IfttierearenWocksof dataD. nvalues. B,. Bj. B3....B„. each 128bitsinlengtt^ of ttie function BH(D)v«1l be generat«L 
To compCite ttie hash over ttie whole data . ttie intermediate results B, are combined as follows: Let (Bi.Bj >represent ttie 
256 number obtained by concatenating ttie 128 blocks Bi and Bj. Then define H(D). ttie hash over the data as; 



H(D) - BH(©H(...(<BH{<BH(<Bi.B2>).B39.B45). - O-Bn?- 
so Alternatively the function H(D) may be of the form; 

H(D) = B ,XOR B jXOR B 3 XOR....B „. 



55 



A prefen-ed hash function for hashing modules, is ttie publicly known function MD5 (MD stands for Message Digest aixJ 
MD5 is described by R. Rivest. THE MD5 MESSAGE DIGEST ALGORITHM. RFC 1321 . April 1992). Once them^u e 
is hashed, the module is tested {47} to determine if it is expected to be changing during ttie program. If it is exp&Aea to 
change, ttie hash value H(D) is not placed in ttie directory, by rattier is appended {48} to tiie module stored in *e niem- 
ory 1 1 . (Alternatively, ttie hash value may be signed (encrypted) witti ttie providers private key. and then appended to 
ttie module stored in memory 1 1). The index i is incremented {56} and ttie next module is accessed from memory. If at 
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{47} the module is deterrraned not to change, a test {49} is made to determine if the module is the Directory Module. If 
it is not the hash value H(M(0) for module M(i) is placed in the Directory Module {50} in either the first security informa- 
tion field, or in the further security information field for the respective module. The index i is incremented {56} and the 
next module is accessed from memory. 

5 If at test {49} the nrvxiule is determined to be the Directory Module, the haished value H(M(0) is applied to the 

encryptor 30 wherein it Is encrypted with the application providers private key. (If desired, the entire Directory Module 
may be applied to the enayptor for encryption at this juncture.) The certificate is fetched {52} and the enaypted hash 
value is appended thereto {53}. and the certificate with the hash value appended is attached {54} to the Directory Mod- 
ule in memory 1 1 . A flag is set {55} which indicates to the data packet processoryprogram controller, that the program 

10 is ready for transmission. The system jumps to step {42} and the index is reset to zero. The system then proceeds to 
check if modules change and only changed modules are rehashed, during repeat transmissions of the application dur- 
ing a program. As noted earlier, an application provider may include other signed information/certificates which may be 
appended to the Directory Module. Signing of such inforn^tion Is performed In the encryptor 30 using the providers pri- 
vate key. 

IS In an alternative embodiment the encryption step 51 may be eliminated. In a still further emtxxliment, all hash val- 
ues for all hashed modules may be encrypted. 

FIGURE 12 illustrates tiie format of a prefened Directory Module. The Directory Module is in plain text Only tiie 
Directory signature (hash value) and the certificate are encrypted, the former with the provider's key and the latter with 
the system controller's key. In addition, when respective nxxdules are hashed, each such module may be preceded with 

20 an ASCII version of some predetermined text associated with the system controDer^rovkJer such as the text 
"OpenTv(TM)" .t?efore hashing, so that respective module signatures are. for example, the hash value 
H(OpenTv(TM)+Moduie). and the Directory Module signature is the encrypted value of H(OpenTv(TM)+Directory Mod- 
ule). This is indicated in Rgure 1 with the box OTV attached to the memory 1 1 , and is meant to inr^ly that a digital ver- 
sion of the text "OpenTv(TM)" is stored therein and may be multiplexed with the respective rrodules when they are read 

^ out and applied to tiie hash function element 29. 

The Directory Module in FIGURE 12 illustrates the pref en-ed format for the AVI system designated OpenTv ™ being 
developed by Thomson Consumer Electronics Inc. The formats of certificates, public keys and signatures used therein 
are described immediately below. 

All certificates, keys arx^ signatures will have multiple byte fields in BIG-ENDIAN format This architecture inde- 

30 pendoTt format facilitates portability across different receiver architectures. Any OpenTV certificate is a combination of 
a fixed structure followed by a variable length part which includes the public key being certified and tiie signature of the 
OpenTV controller. 

There are two classes of certificates thtat will be issued by the OpenTV controller. 

3S 1 . Producer(provider) Certificates which are given to application producers. 

2. Server (system controller) Certificates which are specific to a transaction server to which applications from a pro- 
ducer (provider) can estat^ish secure communications. 

In addition, a USER certifk:ate may be issued by the controller. This certificate will never be parsed internally by 
40 OpenTV, but only made available to the external world. The OpenTV system will only know the size of this certificate. 
Apart from an Open TV specific 4 byte header, the remairxler of the certificate structure may be maintained confidential, 
and may be a standard X.509 certificate. 

The following are thfe sizes for common parts of certificates. 
CERTIF1CATE_FLAQS_LENGTH (4 bytes) 
45 PUBLC_KEY_S1ZE_LENGTH (4 bytes) 

An OpenTV controller issued certificate starts with a 32-bit flag structure which descrtoes the certificate. The location 
and meaning of tiie various flags are described tiiusly 

The flag for possible extensions to the OpenTV certificate structure is set for the Basic Open TV certificate: not to be 

set for extensions. The flags are defined as follows 
so BASIC.CERTIFICATE (0x80000000) 

Exactiy one of the following 3 flags will be set. 

SERVER_CERTIFICATE (0x40000000) 

PRODUCER_CERTlFICATE (0x20000000) 

USER.CERTIFICATE (0x10000000) 
55 There is divergence between tiie SERVER/PRODUCER certificates and the USER certificates as to tiie interpre- 
tation of tiie 32 bit field. If tiie certificate has the appearance of a USER certificate then the last 16 bits of tiie field are 

actually its size including the initial 32 bit field. 

Regarding the SERVER/PRODUCER flags, after examining the first four bits, tiie entity bang certified is known, or 

the certificate is considered to be an extension beyond the current system. The next four bits indicate which OpenTV 
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con«*e, pu«-,c Ke, ,»s been used » ,ene«e .he t^^^^ 

Ihe N* «*ed(l.cl pjllc te, is to be u«d. « N ■ZJ'!;*^'^^^^^^-^^ That is. « Wemally the ke, 
en EXTERNALlRBted channel. Intemellymlh. ^^'"J^'S"^^^^^,^ 6 and certficetes «ilh Keys lese 

i^isi'StS^t'Srci^.o^^rp-rrnSsr.^j^ed^.e™ 

10 and Server so they are described separately. 
The algorithm byte flags are: 

RSA„3_WrrH MD5 (0x00008000) 

link establishment much fester. 



20 



25 



30 



Of Signature, and a 2 byte f ield which gives Ihe size of the signature 
PRODUCER_SIGNATURE_Fl^S_LENGTH (2 bytes) 



PRODUCER SIGNATURE_SIZE_1^NGTH {2 bytes) ■ ^ . ^ =i„«,»hn, ie RSA 3 WITH MD5. as 

2sr:e-*tatr^s.'S?sr^E=^^ 

nature for faster checWng. and tNs is designated 

PRODUCER_SIGNATURE_ASSlST (0x8000) ^ ononTV boxes wiO now be described. For portability. 

The Public Key StrucU^re (for ^^^^^IP^J^-^^^^ 'iZTJZ if a moduli s^e Is 

Str bt S^^^r^Tfrst's". b^^^ rSu^ whi^^esented i^big e^.an fcn^t n.st be NON ZERO. 
This is not a limitation since the size can then be stated to be S-4 or less. 



The pidslic key consists of: 
fixed_public._key_t. 

followed by 

estponent (in big-endian byte format) 

35 followed by 

rrxxlulus (in big-endian byte format) 



rtxxlulus (in big-endian byte forrrat) ^ cAntains a desCTiDtor of the certificate by the OpenTV 

A producer/server certificate consists of a cl^rtext part ^<^ ^^ d^^ltovT In addition there is an end- 
co'ntrooer followed by the pubjic key P™«J^^^ J!;^ ^^^1^^ the deartext data. A 

. srce'^rrtSrrerasTri'^^^^^ 

signature to make it easier to check. Hotw^on the Cleartext and the Signature S, and possibly 

soJ=x^.ireS£t:s'r:^i^^ 

total amount of data consisting of the signature and help informabon. 

45 The sizes of these two fields are: ^ _x 

CERnFiCATE_SIQNATUREJNFO_FLAGS_LENGTH{2 bytes) 

only ^Z-^'J^^^^^'-^^^^ '-^-^ ''^^ ^"^^'^ ' 

wHi* are the two quotients Q1 . Q2 described herein above. Th« flag .s defined. 

so RSA_3_ASSIST (0x8000). «h- module level This may be overtain wHh a further encryption at 

r.r^'p^r^^.'^^itr^sjr^s.r^iri.eJSoJ^ 
'^'^i'n,TtS:,Trsssrr::r9rc=--^^ 

« telephon. n,i),r, lor exen,.le. win inconxKat. "TS^,^ 'ZS^l^Z^ ™a 

OES =n*<««l*W 1».<»antple. Tt» s^ S'se.l^JJ^I^S^to^.^IJS^^ se«ionl>ey is estab- 
r^STA^^^fa^SSl^P^^J ™ e t ^e o«t*.t. e« the .e, exchange use «e 

public key contained in the certif icate. 
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FIGURE 8 illustrates in block form, a portion of AVI signal receiver or IRD Including elements of an inverse transport 
packet processor. Signal is detected by an antenna 80 and applied to a tuner detector, 81 , which extracts a particular 
frequency band of received signals, and provides a baseband multiplexed packet signal. The frequency barxi is 
selected by the user through an IRD system controller 89 (hereafter IRD controller) by conventionar methods. Nominally 

5 broadcast AVI signals will have been error encoded using, for exanrple, Reed-Sotomon forward error correcting (FEC) 
coding. The baseband signals will thus be applied to a FEC decoder. 82. The FEC decoder 82 synchronizes the 
received video and provides a stream of signal packets of the type illustrated in FIGURE 3. The FEC f2 may provide 
packets at regular intervals, or on demand, by for example, memory controller 87. In either case a packet framing or 
synchronizing signal is provided by the FEC circuit, which Indicates the times that respective packet information is trans- 

10 ferred from the FEC 82. 

Only packets from a single AVI signal may be processed by the receiver at one time. In this example it is assumed 
that the user has no knowledge of which packets to select. This information is contained in a program guide, which is a 
special program consisting of data which interrelates program signal components through their respective SCID's. TTie 
program guide is a listing for each program, including the SCID's for the audio, video, and data components of respec- 
15 th/e programs. The program guide (packets D4 in FIGURE 2) is assigned a fixed SCID. When power is applied to the 
receiver, the IRD controller 89 is programmed to load the SCID associated with the program guide into a SCID detector 
84, which may be a bank of matched filters. When the program guide SCID is detected, the menrrary controller 87 is 
conditioned to route the corresponding packet pay load to a predetermined location in the memory 88 for use by the IRD 
controller. 

20 The IRD controller waits for a programming command from the uiser via an interface 90. which is shown as a key- 
tx>ard. txjt which may be a conventional remote corrtrol. or receiver front panel switches. The user may request to view 
a program provided on channel 4 (in the vernacular of analog TV systems). The IRD controller 89 is programmed to 
scan the program guide list that was loaded in the memory 88 for the respective SCID*s of the channel 4 progrEim com- 
ponents, and to load these SCID's in the SCID detector 84. 

25 Received packets of audio, video or data program comporients. for a desired program, must uttimateiy be routed to 
the respective audio 93. video 92, or auxiliary data 91 , (94) signal processors respectively. The data is received at a 
relatively constant rate, but the signal processors nominally require input data in bursts (according to the respective 
types of decompression for example). The exemplary system of FIGURE 8, first routes the respective packets to pre- 
determined memory locations in the memory 88. Thereafter the respective processors 91-94 request the component 

30 packets from the memory 88. Routing the conrponents through the memory provides a measure of desired signal data 
rate txjffering or throttling. 

The audio, video and data packets are loaded into respective predetermined mennory locations to enable the signal 
processors easy access to the component data Payloads of respective component packets are loaded in the appropri- 
ate memory areas as a function of the corresponding SCID*s, and corrtrol signals provided by the SCID detector. This 

35 association may be hardwired in the memory controller 87, or the association may be prograrrtmable. 

The respective signal packets are coupled from the FEC 82 to the memory controller 87 via a signal descrambler 
86. Only the signal payloads are scranrtied and the packet headers are passed by the descrambler unaltered. Whether 
or not a packed is to be descrambled is determined by the CF flag (FIGURE 3) in the packet prefix, and how it is to be 
desaambled is directed by the CS flag. This packet scrambling is independent of the application module security 

40 processing described above. The descramlDling apparatus may be realized with conventional, decryption apparatus, and 
may be utilized to perform decryption of received certificates and other data as required. However in the following 
description of processing transmitted applications, decryption is performed by other apparatus. 

An AVI system maylnclude a number of devices capable of operating with the PC-data portion of an AVI signal. For 
example in FIGURE 8 both of tiie AUX1 and AUX2 processors may be responsive to the PC-data portion of an AVI sig- 

45 nal. The AUX1 processor may be a personal computer, PC, arranged to detect transmitted stock market data and to 
manipulate same with a transmitted interactive application. AUX2 may be a television system arranged to permit inter- 
active impulse buying in conjunction with transmitted interactive commercials. Note, interactivity may be facilitated with 
the aid of a telephone modem (not shown) interconnected with FIGURE 8 system. In addition the IRD corrtroller 89 may 
be programmed to process and execute transmitted applications, particularly for system mairrtenance. The receiver 

so functions related to execution of transmitted interactive applications will be described in the context of the I RD controller 
89 operating with the transmitted application. (It should be noted, that irrteractivity does not necessarily mean that the 
user interacts with the provider, though this is one aspect of interactivity. Interactivity also includes the concept of a user 
k>eing able to affect the signal/system at the user's end of the system in accordance with a transmitted application, par- 
ticularly in the realm of educational programs.) 

55 FIGURE 9 shows the IRD controller of FIGURE 8 in more detail. The IRD cortrdler 89 is shown with a Hash func- 
tion processor 96, a decryptor 97. a modem 98 and an EPROM 99. The hash function generator 96 and the decryptor 
97 may be realized in either hardware or software. The controller processor ftiPC) may include random access memory, 
RAM. and read only memory ROM, for programming general system instructions. Other system insfructions are con- 
tained in the EPROM 99. The ROM and the EPROM are programmed at manufacture so that the system is operable. 
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However in this exam^^e. the EPROM may be r^rogrammed to update system functions ^«a an interactive transn^tted 

program. innk for a svstem maintenance SCID between 1 :00 AM 

Assume that at manufacture the system .s P««rarun^ ^i^Se^^em ^«de^ can update respective receivers 
and 4:00 AM on mornings "'l«^|^^«;;V^r°i^" Sgs^t the reefer is ^use. the ^PC 

:!:;srcsc^d"?sru,^r^^^ 

M to S:eive program data. An example of program module ^^^^f-^" "^JJ^^^f "^'^^^^^ Once the 

The programn^ng for SCID ^f^^^^^^^^^ STf ^^'S^iJ^t^ 'SS::^^e%ao\ 
SCID detector is programmed J^^^^^ determine if it contains a transmission unit or 
detected. When such packet is detected, the Pa<^«J^^ ivstim v^{1021 for the next application packet It is 

is activated to infom, the user that an unauthor^ed P^f ^^^^^^^^^^ for twenty four hours; c) dis- 

possiWe. including a) restarting the process ^^^^JL^^Se^ Rgv^e 1 1 sho^vs the authentication proc- 
carding the Directory Module and wa.bng forfrm ne>d Dirertory hash value appended to 

the module are accessed {1221}. Tne certnicaie is aPP^^ ' . rJ^^& receivers and stored in the receiver. The 

current time and date etc. If ttie compared ''^^J^.^^l^^J^^^Z^e decryptor and used to decrypt 

no, «. b, au^c or .h, ■''f^J-^^S^^^^^SS^S^'S,. hash ^ ^ 
« •» awllcaion prartde. Is proven to *^ '^^T^^X^^^^S^eSyoi) Di.«l»y MoaHe hash «alu. 

gram modules are rMn«ed (,29) (ton, lha dlrecKxy ior use ,n to» not 
Umjunps ,0 s»p I„S, «hi=h«« '^'"^''l^l^i:^^^^^^:^ n»« iproprla. 

memory addressing for the next module is arranged {120} and the system reiurns i luoj 



so 

packet 



55 



•"Tme test at (1.8, indicates that the application program -^^^1^1'^^^ ^iSTS^^iS toTe 
modules are checked for transmission integrity. Respective modules are accessed < fJ^Sj"^'^ cor- 
hash function element 96. and hashed {138}. The resp^e hash ^aVST H the 

responding hash values transmitted in the Directory Module, or appended ^ the partcu^ TSftlSa test is made 
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to access particular data in a program Data Module and reprogram the EPROM wfth the transmitted data. 

Once execution has begun, the system is programmed to continue to extract program packets from the transmitted 
signal. On reception, respective headers are examined for version number. If the version number for a particular module 
changes, this module wilt be hash processed, and if the hash value checks, the module with the new version number 

5 will be substituted for the prior corresponding module. 

As indicated, different apparatus in the receiving apparatus may utilize a particular transmitted application, and may 
be programmed to perform the requisite security processing prior to execution of the application. In the preferred 
embodiment, to avoki duplication of programming or hardware, *the security processing is performed by the IRD con- 
troller. The IRD controller will be alerted when security processing need be performed by infomrtation contained in the 

10 program guide. 

Claims 

1. Apparatus for receiving an executat>le application transmitted In modules including a Directory Module containing 
15 information about further modules, said Directory Module having at least an ^crypted hash value over the Direc- 
tory Module and an encrypted certificate appended, which certificate includes an identity of the application pro- 
vider, said apparatus characterized by: 

a memory (88) 

20 a detector (84) for detecting transmitted said modules and storing detected modules in memory; 

means (89. ^PC) for separating said certificate from a detected Directory Module; 
a decryptor (97) for decrypting said certificate and said encrypted hash value; 

a hash function element (96) for hashing detected said Directory Modules to produce a further hash value; 
a processor (uPC) programmed for authenticating decrypted said certificate, and comparing decrypted said 
25 hash value with said further hash value, and if decrypted said hash value and said further hash value are equal 

arxi said certificate is authentic, permitting execution of said program. 

2. The apparatus set forth in daim 1 wherein said Directory Module further includes hash values of further program 
modules, and said apparatus further characterized by: 

30 

means for accessing said hash values of further program modules from detected said Directory Module: 
means for applying respective said further program modules to said hash function element for generating hash 
values over said further program modules; arKl wherein 

sakl processor is corxjrtioned to compare said hash values of further program modules accessed from sakJ 
35 Directory Module witii corresponding hash values produced by said hash function element and permitting exe- 

cution of said program if at least predetermined ones of cohresponding hash values are equal. 

3. The apparatus set forth in claim 1 characterized in that transmitted said Directory Module is encrypted, and said 
decryptor is conditioned to decrypt said Directory Module with said application provider's putrfic key. 

4. The apparatus set forth in claim 2 characterized in that said processor includes means to delete from said memory, 
modules for which corresporxiing hash values are not identical. 

5. The apparatus set forth in daim 1 characterized in that said decryptor and said hash function element are sub- 
45 sumed in said processor. 

6. The apparatus set forth in daim 1 characterized in that said detector includes forward error oonrecting circuitry. 

7. The apparatus set forth in claim 1 characterized in that transrriitted said executable application is transmitted in 
50 transport packets, each of which includes a service channel identifier. SCID. and scrambling flags, arxl said detec- 
tor indudes: 

a programmable SCID detector for selecting transport packets having predetermined SCID*s from a multi- 
plexed stream of transport p)ackets; and said apparatus further includes 
55 a descrambler responsive to said scrambling flags, for descrambling respective packets according to respec- 

tive states of said scran^ling flags. 

8. The apparatus set forth in claim 1 further characterized by means for causing a display to indicate detection of sig- 
nal provided by an unauthorized application provider. 
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9. The apparatus set forth in claim 1 further characterized by: 

of predetermined text 

1 0 The apparatus set forth in claim 9 characterized in that said predetermined text is OPENTVCTM). 

and Q2 without perforrning arithrrietic division. 

detecting and selecting packets including a desired application, and storing payloads of respective packets as 

respective modules; 

selecting a Directory Module with encrypted certificate attached: 

decrypting the certificate with the system provider-s public key: 

C^^ng infomation in decrypted said certificate with corr^ponding stored data. 

applicaL provider's private key. and said method further characterKed by the steps of . 

extracting said application provider's public key from decrypted said certificate and separating encrypted said 
hash value from said Directory Module; , , . 

of the text Opeffrv(tm) appended. 

Apparatus for transmitting executable applications characterized by: 

XLspcn f»oc««r (14.16) to, fo-^ina a time di«on r™«ipl»ed signal w» said modules ol said appiica- 



14. 



f 15. 
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1 6. The apparatus set forth in claim 1 5 further characterized by: 

enayption apparatus for encrypting a hash value of said Directory Module containing hash values of said appli- 
cation modules, with a private key of said application provider; and 

means for attaching encrypted said hash value of said Directory Module to said Directory Module. 

17. The apparatus set forth in daim 15 characterized in that ones of said modules are Data Modules in which data is 
expected to change during execution of said application, and said processor appGes version nun±>ers to respective 
modules, and changes the version number of a module when such module changes; 

said hash function element hashes each changed version of a module to produce a new hash value arxj coop- 
erates with said processor to attach said new hash value to the module to which it corresponds. 

18. The apparatus setforth in daim 15 further characterized by: 

a source of a digital version of predetermined text; 

a multiplexer for multiplexing said digital version of predetermined text with said Directory Module, wherein said 
hash function element is conditioned to hash the combination of said digital version of predetermined text and 
the Directory Module. 

19. A metiiod of ti-ansmitting executable applications diaracterized by: 

generating an executable application arxj segmenting it into modules; 

forming a Directory Module including information linking respective application modules; 

hashing respective modules with a one way hash function to generate hash values for respective modules; 

including hash values for respective modules in saki Directory Module; 

accessing a certif k:ate including an application provkler's identity which certificate is encrypted with a system 
controller's private key; and 

attaching the certificate to said Directory Module, and transmitting said applicatioa 

20. The method set forth in daim 19 further characterized by: 

hashing the directory Module with hash values included therein, to generate a Directory Module hash value; 
enaypting the Directory Module hash value; 

attaching encrypted said Directory Module hash value to said Directory Module; 

21 . The method set forth in daim 19 further characterized tiy: 

generating a further certificate including identification of a third party provider; 
encrypting the further certificate with the application provider's private key; and 
attadiing encrypted. said further certificate to said Directory Module. 

22. The method set forth in daim 20 further characterized by: 

encrypting said Directory Module with an application provider's private key. and transmitting said encrypted 
<^ Directory Module; and 

transmitting remaining application modules in plain text 

23- The method set forth in daim 1 9 characterized in that the step of including hash values in satd Directory Module 
indudes respective hash values of 1 28 bit length; and 

the step of attaching the certificate to said Directory Module indudes attaching a Certificate induding: 

a 32 bit certificate descriptcs- or flags. 

a32bitlD. 

a 32 bit lifetime expiration descriptor, 
a 32 bit file storage limit, 
a 128 bit name, and 
a 32 bit public key. 
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PREFIX 
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STAFU: APPLICATION DESCRIPTOR (RXED LENGTH PART): 



- PRODUCER CERTIFICATE OFFSET (CERTIFICATE ADDRESS = START + OFFSET) 
-APPLICATION NAME OFFSET (APPUCATION NAME ADDRESS = START + OFFSET) 
APPUCATIONID (32 BITS) 

APPUCATION LIFE EXPIRATION (32 BITS) 

APPUCATION AUTHORIZATION MASK (32 BITS) 

APPUCATION FILE STORAGE UMIT (32 HITS) 

APPUCATION MINI REGL'!«B/IENTS (32 BITS) 

APPLICATION MODULE NUMBER (32 BITS) 

FOR EACH MODULE, MODULE DESCRIPTOR (RXED LENGTH PART): 

■ MODULE NAME OFFSET (MODULE NAME ADDRESS = START + OFFSET) 
MODULE ID (16 BITS) 

MODULE SIZE (32 BITS) 

NiSbULE REQUIREMENT (32 BITS) 

MODULE LOADING FUGS (32 BITS) 

FOR §ACH MODULE, MODULE DESCRIPTOR (VARIABLE LENGTH PART): 
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